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Abstract.  Interface  formalisms  are  able  to  model  both  the  input  requirements 
and  the  output  behavior  of  system  components;  they  support  both  bottom-up 
component-based  design,  and  top-down  design  refinement.  In  this  paper,  we  pro¬ 
pose  “sociable"  interface  formalisms,  endowed  with  a  rich  compositional  seman¬ 
tics  that  facilitates  their  use  in  design  and  modeling.  Specifically,  we  introduce 
interface  models  that  can  communicate  via  both  actions  and  shared  variables,  and 
where  communication  and  synchronization  covers  the  full  spectrum,  from  one-to- 
one,  to  one-to-many,  many-to-one,  and  many-to-many.  Thanks  to  the  expressive 
power  of  interface  formalisms,  this  rich  compositional  semantics  can  be  realized 
in  an  economical  way,  on  the  basis  of  a  few  basic  principles.  We  show  how  the 
algorithms  for  composing,  checking  the  compatibility,  and  refining  the  resulting 
sociable  interfaces  can  be  implemented  symbolically,  leading  to  efficient  imple¬ 
mentations. 


1  Introduction 

Interface  theories  are  formal  models  of  communicating  systems.  Compared  to  tradi¬ 
tional  models,  the  strength  of  interface  theories  lies  in  their  ability  to  model  both  the 
input  requirements,  and  the  output  behavior,  of  a  system.  This  gives  rise  to  a  compat¬ 
ibility  test  when  interface  models  are  composed:  two  interfaces  are  compatible  if  there 
is  a  way  to  use  them  (an  environment)  in  which  their  input  assumptions  are  simultane¬ 
ously  satisfied.  This  ability  to  model  input  assumptions  and  provide  a  compatibility  test 
makes  interface  models  useful  in  system  design.  In  particular,  interface  models  support 
both  bottom-up,  and  top-down,  design  processes  [6,7].  In  a  bottom-up  direction,  the 
compatibility  test  can  be  used  to  check  that  portions  of  the  design  work  correctly,  even 
before  all  the  components  are  assembled  in  the  final  design.  In  a  top-down  direction, 
interface  models  enable  the  hierarchical  decomposition  of  a  design  specification,  while 
providing  a  guarantee  that  if  the  components  satisfy  their  specifications,  then  they  will 
interact  correctly  in  the  overall  implementation. 
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In  this  paper  we  present  interfaces  models  that  can  communicate  via  both  actions 
and  variables,  and  that  provide  one-to-one,  many-to-one,  one-to-many,  and  many-to- 
many  communication  and  synchronization.  We  show  that  this  rich  communication  se¬ 
mantics  can  be  achieved  by  combining  a  small  number  of  basic  concepts,  thanks  to 
the  expressive  power  of  interface  models.  This  leads  to  an  uniform,  and  conceptually 
simple,  communication  model.  We  call  this  model  sociable  interfaces,  underlining  the 
ease  with  which  these  interfaces  can  be  composed  into  models  of  design.  While  socia¬ 
ble  interfaces  do  not  break  new  ground  in  the  conceptual  theory  of  interface  models, 
we  hope  that  they  constitute  a  useful  step  towards  a  practical,  interface-based  design 
methodology. 

In  sociable  interfaces,  synchronization  and  communication  are  based  on  two  main 
ideas.  The  first  idea  is  that  the  same  action  can  appear  as  a  label  of  both  input  and  output 
transitions:  when  the  action  labels  output  transitions,  it  means  that  the  interface  can  emit 
the  action;  when  the  action  labels  an  input  transition,  it  means  that  the  action  can  be 
accepted  if  sent  from  other  components.  Depending  on  whether  the  action  labels  only 
input  transitions,  only  output  transitions,  or  both  kind  of  transitions,  we  have  different 
synchronization  schemes.  For  instance,  if  an  action  a  is  associated  only  with  output 
transitions,  it  means  that  the  interface  can  emit  a ,  but  cannot  receive  it,  and  thus  it 
cannot  be  composed  with  any  other  interface  that  emits  a.  Conversely,  if  a  is  associated 
only  with  input  transitions,  it  means  that  the  interface  accepts  a  from  other  interfaces, 
but  will  not  emit  a.  Finally,  if  a  is  associated  both  with  input  and  output  transitions,  it 
means  that  the  interface  can  both  emit  a,  and  accept  a  when  emitted  by  other  interfaces. 

The  second  idea  is  that  global  variables  do  not  belong  to  specific  interfaces:  the 
same  global  variable  can  be  updated  by  multiple  interfaces.  In  an  interface,  the  output 
transitions  associated  with  an  action  specifies  how  global  variables  can  be  updated  when 
the  interface  emits  the  action;  the  input  transition  associated  with  an  action  specifies 
constraints  on  how  other  interfaces  can  update  the  global  variables  when  emitting  the 
action.  By  limiting  the  sets  of  variables  whose  value  must  be  tracked  by  the  interfaces, 
and  by  introducing  appropriate  non-interference  conditions  among  interfaces,  we  can 
ensure  that  interfaces  can  participate  in  complex  communication  schemes  with  limited 
knowledge  about  the  other  participants.  In  particular,  interfaces  do  not  need  to  know  in 
advance  the  number  or  identities  of  the  other  interfaces  that  take  part  in  communication 
schemes.  This  facilitates  component  reuse,  as  the  same  interface  model  can  be  used  in 
different  contexts. 

We  show  that  the  compatibility  and  refinement  of  sociable  interfaces  can  be  checked 
via  efficient  symbolic  algorithms.  We  have  implemented  these  algorithms  in  a  tool 
called  TIC  (Tool  for  Interface  Compatibility);  the  tool  is  written  in  Ocaml  [10],  and 
the  symbolic  algorithms  for  interface  compatibility  and  refinement  are  built  on  top  of 
the  MDD/BDD  Glue  and  Cudd  packages  [13, 12], 

The  paper  is  organized  as  follows.  First,  we  introduce  sociable  interface  automata, 
which  include  actions,  but  not  variables,  and  which  are  a  more  “sociable”  version  of 
the  interface  automata  of  [6, 8],  After  illustrating  the  various  synchronization  and  com¬ 
munication  features  for  sociable  interface  automata,  we  endow  them  with  variables  in 
Section  3,  obtaining  sociable  interface  modules.  We  describe  the  communication  mech¬ 
anisms  of  sociable  interface  modules  via  examples,  and  we  show  how  the  examples  can 


(a)  C:  Control  Unit  (b)  D\ :  Fire  Detector  1  (c)  ZU:  Fire  Detector  2 

Fig.  1.  Sociable  interface  automata  for  a  fire  detection  and  reporting  system. 


be  encoded  in  the  input  language  of  the  tool  TIC.  The  refinement  of  sociable  interfaces 
is  discussed  Section  4,  and  the  symbolic  implementation  of  the  composition  and  re¬ 
finement  algorithms  is  in  Section  5.  We  conclude  with  a  comparison  between  sociable 
interfaces  and  previous  interface  formalisms. 


2  Sociable  Interface  Automata 

Social  interfaces  communicate  via  both  actions  and  variables.  We  first  illustrate  how 
sociable  interfaces  communicate  via  actions;  in  the  next  section,  we  will  augment  them 
with  variables,  obtaining  the  model  implemented  in  the  tool  TIC.  We  begin  with  an 
informal,  intuitive  preview,  which  will  motivate  the  definitions. 

2.1  Preview 

To  provide  some  intuition  on  sociable  interfaces,  we  present  an  example:  a  very  simple 
model  of  a  fire  detection  and  reporting  system.  The  sociable  interfaces  for  this  example 
are  depicted  in  Figure  1:  D\  and  TU  are  the  fire  detectors  (there  could  be  more),  and 
C  is  the  control  unit.  When  the  fire  detectors  D\  and  Z)i  detect  smoke  (input  events 
smoke  i  ?, smoke  2?),  they  generate  an  output  event  fire!.  The  control  unit,  upon  receiving 
the  input  event  fire?,  issues  a  call  for  the  fire  department  (output  event  I  I)!).  Similar 
to  the  original  interface  model  [6,8],  the  input  and  output  transitions  departing  from  a 
state  of  a  sociable  interface  denote  the  inputs  that  can  be  received,  and  the  outputs  that 
can  be  generated,  from  that  state.  For  instance,  the  sociable  interface  C  (Figure  1(a)) 
specifies  that  input  event  fire?  can  be  accepted  at  state  1,  but  not  at  state  2. 

Product  and  composition.  To  compose  two  sociable  interfaces,  we  first  form  their  au¬ 
tomata  product.  In  the  product,  shared  output/input  events  (such  as  the  pair  fire! -fire?  in 
Figure  1)  synchronize:  this  models  communication,  or  synchronization,  initiated  by  the 


(a)  C®D\ 


(b)  £>i®D2 


Fig.  2.  Product  of  the  automata  D\,  D 2.  and  C. 


interface  issuing  the  output  transition.  Similarly,  two  interfaces  can  also  synchronize  on 
shared  inputs:  when  the  environment  generates  an  input,  both  interfaces  will  receive  it 
and  take  the  corresponding  input  transition.  However,  interfaces  do  not  synchronize  on 
shared  outputs:  as  an  example,  D\  and  Z)2  do  not  synchronize  on  the  output  event  fire! 
in  their  product  D\  <8 >Z)2  (Figure  2(b)).  The  idea  is  that,  in  an  asynchronous  model,  inde¬ 
pendent  components  issue  their  output  asynchronously,  so  that  synchronization  cannot 
happen.  As  usual,  interfaces  do  not  synchronize  on  non-shared  actions. 

In  the  product  of  two  interfaces,  we  distinguish  between  good  and  bad  states.  A 
state  is  good  if  all  the  outputs  produced  by  one  component  can  be  accepted  as  inputs 
by  the  other  component;  a  state  is  bad  otherwise.  For  instance,  in  the  product  C®Z>i 
(Figure  2(a)),  the  states  (2,2)  and  (3,2)  are  bad,  since  from  state  2  the  detector  D\  can 
issue  fire!,  and  this  cannot  be  matched  by  an  input  transition  fire?  neither  from  state  2 
nor  from  state  3  of  the  control  unit. 

A  state  of  the  product  is  compatible  if  there  is  an  Input  strategy  that  can  avoid 
all  bad  states:  this  means  that  starting  from  that  state,  there  is  an  environment  under 
which  the  component  interfaces  interact  correctly.  The  composition  of  two  interfaces  is 
obtained  by  removing  all  incompatible  states  from  the  product.  The  composition  C\\D\ 
of  C  and  D \  is  depicted  in  Figure  3(a),  and  the  composition  of  C\\D\  || Z)2  is  depicted 
in  Figure  3(b).  Notice  that  in  the  composition  C\\D\  ||Z)2,  once  smoke \  (resp.  smokei)  is 
received,  smoke2  (resp.  smoke i)  is  not  allowed.  This  behavior  results  from  the  design  of 
the  control  unit  which  cannot  accept  more  than  one  “smoke-input”  before  issuing  FD! . 

Multi-way  communication.  In  a  sociable  interface,  the  same  action  can  label  both  input 
and  output  transitions:  this  is  illustrated,  for  instance,  by  action  fire  in  Figures  1(b) 
and  1(c).  Indeed,  sociable  interfaces  do  not  have  separate  input  and  output  transition 


(a)C||D! 


(b)C||Di||fl2 

Fig.  3.  Composition  of  the  automata  D\,  Do,  and  C. 


alphabets:  rather,  they  have  a  single  action  alphabet,  and  actions  in  this  alphabet  can 
label  edges  both  as  inputs,  giving  rise  to  input  transitions,  and  as  outputs,  giving  rise  to 
output  transitions.  For  example,  the  action  fire  at  state  2  of  D\  corresponds  to  both  an 
output,  and  to  an  input  transition:  this  indicates  that  D\  can  generate  output  /z're,  while  at 
the  same  time  being  composable  with  other  interfaces  that  generate  fire  as  output  (such 
as  Do).  Thus,  if  an  action  a  is  in  the  alphabet  of  an  interface,  there  are  four  cases: 

-  If  a  is  not  associated  with  any  transition,  then  the  interface  neither  outputs  a ,  nor 
can  it  be  composed  with  other  interfaces  that  do. 

-  If  a  is  associated  with  output  transitions  only,  then  the  interface  can  generate  a,  but 
it  cannot  be  composed  with  interfaces  that  also  output  a. 

-  If  a  is  associated  with  input  transitions  only,  then  the  interface  can  receive  a,  but 
not  output  it. 


(a)  Se:  Sender 


(b)  Re:  Receiver 


Fig.  4.  A  simple  communication  protocol. 


-  If  a  is  associated  with  both  input  and  output  transitions,  then  the  interface  can  gen¬ 
erate  a,  and  it  can  be  composed  with  other  interfaces  that  do. 

We  notice  how  these  four  cases  all  arise  in  an  uniform  way  from  our  interpretation 
of  input  and  output  edges.  All  of  these  cases  have  a  use  in  system  modeling:  the  fire 
detector  example  illustrated  the  non-exclusive  generation  of  outputs,  the  next  example 
illustrates  exclusive  generation. 

Figure  4  depicts  a  simple  communication  protocol.  In  this  protocol,  the  sender  Se, 
after  receiving  information  from  the  environment  (label  produce?),  sends  this  informa¬ 
tion  to  the  receiver  (label  send!),  and  awaits  for  an  acknowledge  (label  ack?).  The  lack 
of  input  edges  labeled  with  send  in  Se,  and  the  lack  of  input  edges  labeled  with  ack  in 
Re  indicate  that  the  communication  channel  between  Se  and  Re  is  not  shared:  only  Se 
can  generate  send  actions,  and  only  Re  can  generate  ack  actions. 

2.2  Definitions 

Given  two  sets  A  and  B,  we  denote  with  A  =4  B  the  set  of  nondetenninistic  functions 
from  A  to  B,  that  is:  A  — >  2B . 

Definition  1  (Sociable  Interface  Automaton).  A  sociable  interface  automaton  (au¬ 
tomaton  for  short)  is  a  tuple  M  =  ( Act.S ,  X1 ,  x°,  (p1 ,  (p°),  where: 

-  Act  is  a  set  of  actions. 

-  S  is  a  set  of  states. 

-  x1 :  Act  x  S  S  is  the  input  transition  function. 

-  x°  :  Act  x  S  =4  S  is  the  output  transition  function. 

-  (p1  C  S  is  the  input  invariant. 

-  (p°  C  S  is  the  output  invariant. 

We  require  x1  to  be  deterministic,  that  is:  for  all  s  £  S  and  a  €  Act,  K7(a,s)|  <  1. 


For  all  s  £  S  and  a  £Act,  we  define  X1  (a.s)  =  X1  (a,s)r\(pI ,  and  x°(a,s)  =  X° (a ,  s)  fl  (p° . 
Together,  S ,  T/  and  x°  define  a  graph  whose  edges  are  labeled  with  actions  in  Act.  As 
it  was  already  informally  done  in  the  examples  of  Section  2.1,  we  therefore  depict 
interface  automata  as  graphs.  To  distinguish  input  from  output  transitions,  we  add  a  tag 
at  the  end  of  the  name  of  the  action:  as  in  process  algebra  notation,  we  add  “?”  for  input 
transitions  and  “!”  for  output  transitions.  In  all  examples,  it  holds  <p!  =  <p°  =  S. 

Example  1.  Figure  1(b)  is  a  graphical  representation  of  a  3-state  automaton  whose  ac¬ 
tions  art  fire,  and  smoke i.  For  instance,  from  state  2,  the  automaton  can  take  an  input 
transition  fire?,  as  well  as  an  output  transition  fire!. 

The  semantics  of  a  sociable  interface  automaton  can  be  described  in  terms  of  a 
game  between  two  players.  Input  and  Output,  played  over  the  graph  representation  of 
the  automaton.  At  each  round,  from  the  current  state  in  the  graph,  the  Input  player 
chooses  an  outgoing  input  edge,  and  the  Output  player  chooses  an  outgoing  output 
edge.  In  order  to  ensure  that  both  players  always  have  an  enabled  move,  we  introduce 
a  special  move  Aq  which,  when  played,  gives  rise  to  a  stuttering  step,  that  is,  a  step 
that  does  not  change  the  current  state  of  the  automaton.  Furthermore,  we  postulate  that 
player  Output  (resp.  Input)  can  choose  only  edges  that  lead  to  states  where  the  output 
(resp.  input)  invariant  holds.  Thus,  input  and  output  invariants  are  used  to  restrict  the 
set  of  moves  available  to  the  players;  their  true  usefulness  will  become  clearer  when 
considering  interfaces  with  variables,  i.e.  modules. 

In  the  remaining  of  this  section,  we  consider  a  fixed  sociable  interface  automaton 
M  =  (ActM ,  Sm ,  Tvf  ■  (prM,  $>]$).  The  sets  of  enabled  moves  can  be  defined  as  follows. 

Definition  2  (Moves).  For  all  s  £  Sm,  the  set  of  moves  for  player  Input  at  s  is  given  by: 

r\M,s)  =  {A0}  U  {(a, s')  £  ActM  x  SM  \  s’  £  X JM(a,s)}. 

Similarly,  the  set  of  moves  for  player  Output  at  s  is  given  by: 

r°(M,s)  =  {A0}U{(a,s')  £ActM  x  SM  \  s’  £  X&(a,s)}. 

Example  2.  Consider  the  automaton  D\  of  Example  1,  we  have  that  T1  [D\ .  1 )  = 
{A0,{fire,  1),  (smoke , , 2)},  and  r°(Dh2)  =  {A0,(fire, 3)}. 

At  each  game  round,  both  players  choose  a  move  from  the  corresponding  set  of  enabled 
moves.  The  outcome  of  their  choice  is  defined  as  follows. 

Definition  3  (Move  Outcome).  For  all  states  s  £  Sm  and  moves  m1  £  r\M,s)  and 
m°  £  r°(M,s),  the  outcome  8(M,s,aI ,a°)  £  Sm  of  playing  m1  and  m°  at  s  can  be 
defined  as  follows,  according  to  whether  m1  and  m°  are  Aq  or  a  move  of  the  form 
{a,  s'). 

8(M,s,A0,A0)  =  {.?},  8{M,s,A0,(a,s'))  =  {/}, 

8(M,s,  ( a,s'),AQ )  =  {s'},  8{M,s,  (a, s'),  ( b,t '))  =  -j>'/}. 


A  strategy  represents  the  behavior  of  a  player  in  the  game.  A  strategy  is  a  function  that, 
given  the  history  of  the  game,  i.e.,  the  sequence  of  states  visited  in  the  course  of  the 
game,  yields  one  of  the  player’s  enabled  moves. 

For  s  £  5m.  we  define  the  set  of  finite  runs  starting  from  s  as  the  set  Runs(M,s)  C 
S*M  of  all  finite  sequences  ,s'o.V|  ,s'2 . . .  sn,  such  that  so  =  s,  and  for  all  0  <  i  <  n,  s(+  [  £ 
8(M,Si,mI ,m°),  for  some  m1  £  r!(M,Si),  m°  £  r°(M,s,).  We  also  set  Runs(M)  = 
UseSMRuns(Mis)- 

Definition  4  (Strategy).  A  strategy  for  player  p  £  {/,  0}  in  an  automaton  M  is  a  func¬ 
tion  7lp  :  Runs{M )  — >  ActM  U  {Ao}  that  associates,  with  every  run  a  £  Runs(M)  whose 
final  state  is  s,  a  move  np(o)  £  rp(M,s).  We  denote  by  11$  and  77^  the  set  of  input 
and  output  strategies  for  M,  respectively. 

An  input  and  an  output  strategy  jointly  determine  a  set  of  outcomes  in  Ritns(M). 

Definition  5  (Strategy  Outcome).  Given  a  state  s  £  Sm ,  an  input  strategy  n1  £  11$ 
and  an  output  strategy  7t°  £  11$,  the  set  outcomes  (5(M,j,,7T/  ,n°)  of  n1  and  n°  from 
s  consists  of  all  finite  runs  a  =  sosiS2 . .  .s„  such  that  .v  =  so.  and  for  all  0  <  i  <  n, 
Si+i  G  8(M,Si,nI((Jo:i),K°(ao:i)),  where  Oqj  denotes  the  prefix  sosis2  •••*,'  of  cr. 

Definition  6  (Winning  States).  Given  a  state  s  £  Sm  and  a  goal  y  C  RunsiM .s),  we 
say  that  s  is  winning  for  input  with  respect  to  y,  and  we  write  s  £  Win1  (M ,  y),  iff  there 
is  7t 1  £  11$  such  that  for  all  n°  £  TI$,  8(M,s,  tt1 ,  7t°)  C  y.  Similarly,  we  say  that  s  is 
winning  for  output  with  respect  to  y,  and  we  write  s  £  Win°(M ,  y),  iff  there  is  7t°  £  77 $ 
such  that  for  all : i1  £  11$,  8(M,s,  tz1 ,7t°)  C  y. 

A  state  of  an  automaton  is  well-formed  if  both  players  have  a  strategy  to  always  sat¬ 
isfy  their  own  invariant.  Following  temporal  logic  notation,  for  all  X  C  Sm,  we  de¬ 
note  by  OX  the  set  of  all  runs  in  Runs(M )  all  whose  states  belong  to  X.  Formally, 
OX  =  {^0*1*2  ■  •  -s,,  £  Runs(M)  |  VO  <i<n.  Si£X}. 

Definition  7  (Well-formed  State).  We  say  that  a  state  s  £  Sm  is  well-formed  iff .?  £ 

WinI(M,0(pIM)OWin°{M,0(pOy 

Notice  that  if  s  is  well-formed,  then  s  £  (p$  H  < Pm ■ 

Definition  8  (Normal  Form).  We  say  that  M  is  in  normal  form  iff  (p$  — 
Win1  (M,  □<),  and  <  =  Win°{M,  □<). 

Given  an  automaton  M\ ,  we  can  define  an  automaton  M 2  such  that  the  well-formed 
portion  of  M\  coincides  with  the  one  of  Mi,  and  Mi  is  in  normal  form.  Let 
Mi  =  (Acti,S\,x[,T\  ,<p[,<pP),  we  set  M2  =  (Acti,Si,T2,T2  ,$2,^2),  where,  (p{  = 
Win1  (M] ,  D<p[)  and  (p?  =  Win1  (M\,Oq>°).  Thus,  in  the  following,  unless  differently 
specified,  we  only  consider  automata  in  normal  form. 

Definition  9  (Well-formed  Automaton).  We  say  that  M  is  well-formed  iff  it  is  in  nor¬ 
mal  form,  and  (p$ 


Lemma  1.  IfM  is  in  normal  form,  then  it  holds: 

Vs  G  <Pm  .Va  G  r°(M,s)  .T^(a,s)  C 
Vs  G  (p^  .  Va  G  r\M,s)  .  T$(a,s)  C  <p^. 

Proof.  For  the  first  statement,  by  contradiction,  suppose  there  is  s  G  (p'M  and  a  G 
r°(M,s)  such  that  f^(a,s)  %  (p!M.  Then  s  Win1  (M ,  because  there  is  no  way  for 

the  Input  player  to  prevent  output  a  to  be  carried  out  (see  Definition  3).  This  contrasts 
with  the  assumption  that  M  is  in  normal  form.  The  second  statement  can  be  proven 
along  similar  lines. 


2.3  Compatibility  and  Composition 

In  this  subsection,  we  define  the  composition  of  two  automata  M\  — 
(Acr i , 51! ,  t{ ,  tP ,  ,  <jt>P )  and  Mt  =  {Act2.S2.T2,  T%,  (pf  (p®).  We  first  define  the 
product  between  M\  ®M2  as  the  classical  automata-theoretic  product,  where  M\  and 
M2  synchronize  on  shared  actions  and  evolve  independently  on  non-shared  ones.  We 
then  identify  a  set  of  incompatible  states  where  M\  can  do  an  output  transition  that 
is  not  accepted  by  Mi  or  vice-versa.  Finally,  we  obtain  the  composition  M\  \  \Mi  from 
M 1  0  Mi  by  strengthening  the  input  assumptions  of  M\  <g>  Mi  in  such  a  way  that  M\  and 
Mi  mutually  satisfy  their  input  assumptions. 

Definition  10.  We  define  the  set  of  shared  actions  of  M\  and  Mi  by: 

Shared{M\,Mi)  =  Act\  C\Act2- 

The  product  of  two  automata  M\  and  Mi  is  an  automaton  M\  0  Mi,  representing  the 
joint  behavior  of  M\  and  M2.  Similarly  to  other  interface  models,  for  each  shared  ac¬ 
tion,  the  output  transitions  of  M\  synchronize  with  the  input  transitions  of  Mi,  and 
symmetrically,  the  output  transitions  of  Mi  are  synchronized  with  the  input  transitions 
of  M\ .  This  models  communication,  and  gives  rise  to  output  transitions  in  the  product. 
The  input  transitions  of  M\  and  Mi  corresponding  to  shared  actions  are  also  synchro¬ 
nized,  and  lead  to  input  transitions  in  the  product.  Output  transitions,  on  the  other  hand, 
are  not  synchronized.  If  both  M\  and  Mi  can  emit  a  shared  action  a,  they  do  so  asyn¬ 
chronously,  so  that  their  output  transitions  interleave.  As  usual,  the  automata  interleave 
asynchronously  on  transitions  labeled  by  non-shared  actions. 


Definition  11  (Product).  The  product  M\  0  Mi  is  the  automaton  M\i  = 
(Acfi2,Si2,Ti2>Ti2)<Pi2;<)!,i2),  consisting  of  the  following  components. 

-  Act\i  =  Act\  U Acti\  S\2  =  S\X.S2. 

-  <Pl2  =  <Pl  X  <P2'  <Pl°2  =  <p?  X  <P2- 

-  For  a  G  Shared  {Mi,  M2), 


(s'A  G  T°2(a,{s,t))  iff 


s'  G  T°{a,s)  and  t'  G  ^[{af)  or 
t'  G  T2(a’t)  and  s'  G  t[ (a,s) 

( s' ,t ')  G  T [2{a,  ( s,t ))  iff  s'  G  r((a,s)  and  t'  G  ri{a,t). 


-  For  a  G  Act\  \Act2, 


(s',t)  G  T^(a,  ( s,t ))  iff  s'  G  Ti(a,s) 

( s',t )  G  T(2(a,  (s,f))  iff  /  G  Tf(a,s). 

-  For  a  G  Acti  \  Act] , 

(«/)  G  T,°2(a,  (s,t))  iff  t'  G  T2° (a,f) 

(•*/)  G  x[2{a,  (s,t))  iff  t'  G  X i{a,t). 

Example  3.  The  sociable  interface  automaton  depicted  in  Figure  2(a)  is  the  product 
C'/jD\  of  the  automata  depicted  in  Figures  1(a)  and  1(b).  For  instance,  the  input  transi¬ 
tion  fire?  from  state  (1,1)  to  state  (2,1)  is  obtained  by  combining  the  input  transition 
fire?  from  state  1  to  state  2  in  C  with  the  input  transition  fire?  from  state  1  to  state  1  in 
D\.  The  output  transition  FD!  from  state  (1,2)  to  state  (2,3)  is  obtained  by  combining 
the  input  transition  fire?  from  state  1  to  state  2  in  C  with  the  output  transition  fire!  from 
state  2  to  state  3  in  D\ . 

We  have  the  following  theorem. 

Theorem  1.  The  product  is  a  commutative  and  associative  operation,  up  to  isomor¬ 
phism. 

The  product  M j 2  =  M\  '/>  M2  may  contain  states  in  which  one  of  the  components,  say 
M\ ,  can  do  an  output  transition  labeled  by  a  shared  action  while  the  other  component 
cannot  do  the  corresponding  input  transition.  This  constitutes  a  violation  of  the  input 
assumptions  of  M2.  We  formalize  such  notion  by  introducing  a  local  compatibility  con¬ 
dition.  To  this  end,  for  p  G  {/,  O},  we  denote  by  Enp(M,a)  the  set  of  states  of  M  where 
the  action  a  is  enabled  as  input  if  p  =  /,  and  as  output  if  p  =  O.  Formally, 

Enp(M,a)  =  {i  G  SM  \  a,s )  ^0}. 

Definition  12  (Local  Compatibility).  Given  (s,t)  G  S\2,  ( s,t )  G  good(M\  ,M2)  iff,  for 
all  a  G  Shared {M\,M2)  the  following  conditions  hold: 

s  G  En°(M\,a)  =>  t  G  En1  (M2,a) 
t  G  En°(M2,a)  =>■  s  G  En1  (M\,a). 

Example  4.  Consider  the  product  C®D\  of  Example  4.  The  state  (3,2)  does  not  satisfy 
the  Local  Compatibility  condition  because,  from  state  2,  Z>i  can  issue  an  output  tran¬ 
sition  fire!,  and  this  cannot  be  matched  by  an  input  transition  fire?  from  state  3  of  the 
control  unit. 

The  composition  of  M\  and  M2  is  obtained  from  the  product  M\  ®M2  by  strengthening 
the  input  assumptions  of  M\  ®M2  to  avoid  states  that  are  not  in  good  (Mi,  M2).  This  is 
done  by  restricting  the  input  invariant  <p[,  as  shown  in  the  next  definition.  The  reason 
for  restricting  only  the  input  behavior  is  that,  when  composing  automata,  only  their 
input  assumptions  can  be  strengthened  to  ensure  that  no  incompatibility  arises,  while 
their  output  behavior  cannot  be  modified. 


Definition  13  (Composition).  Assume  M\  and  M2  are  compatible.  The  composition 
M 1 ||M2  is  a  sociable  interface  automaton  identical  to  Mi  ®  M2,  except  that  <p^  ^  = 

(pf2  n  Win1  {M  \2,  n((p[2C\good(Mi,M2))). 

Definition  14  (Compatibility).  We  say  that  M\  and  M2  are  compatible  if  <p'M^  n 

|| Mi  ^  ®- 

The  following  theorem  states  that  once  the  input  transition  relations  have  been  strength¬ 
ened,  the  automaton  is  in  normal  form:  it  is  not  necessary  to  also  strengthen  the  output 
transition  relations.  This  result  thus  provides  a  sanity  check,  since  strengthening  the 
output  transitions  means  restricting  the  output  behavior  of  the  interfaces,  which  is  not 
reasonable. 

Theorem  2.  If  M  \  and  Mi  are  compatible ,  and  they  are  in  normal  form,  then  M\  ||M2 
is  in  normal  form. 

The  following  result  implies  that  the  automata  can  be  composed  in  any  order. 

Theorem  3.  The  composition  is  a  commutative  and  associative  operation,  up  to  iso¬ 
morphism. 


3  Sociable  Interfaces  with  Variables 

3.1  Preview 

In  modeling  systems  and  designs,  it  is  often  valuable  to  have  a  notion  of  global  state, 
which  can  be  read  and  updated  by  the  various  components  of  the  system.  A  common, 
and  flexible,  paradigm  consists  in  having  the  global  state  consist  of  a  value  assignment 
to  a  set  of  global  variables.  Once  the  global  state  is  represented  by  global  variables,  it 
is  natural  to  encode  also  the  local  state  of  each  component  via  (local)  variables. 

Previous  interface  models,  such  as  interface  automata  [6, 8]  and  interface  modules 
[7, 3]  were  based  on  either  actions,  or  variables,  but  not  both.  In  sociable  interfaces, 
however,  we  want  to  have  both:  actions  to  model  synchronization,  and  variables  to 
encode  the  global  and  local  state  of  components.  In  this,  sociable  interfaces  are  closely 
related  to  the  I/O  Automata  Language  (IOA)  of  [1 1], 

Interface  models  are  games  between  Input  and  Output,  and  in  the  models,  it  is  es¬ 
sential  that  Input  and  Output  are  able  to  choose  their  moves  independently  from  one 
another.  To  this  end,  in  previous  interface  formalisms  with  variables,  the  variables  were 
partitioned  into  input  and  output  variables  [7, 3].  A  move  of  Input  consisted  in  choosing 
the  next  value  of  the  input  variables,  and  a  move  of  Output  consisted  in  choosing  the 
next  value  of  the  output  variables:  this  ensured  the  independence  of  the  moves.  Conse¬ 
quently,  interfaces  sharing  output  variables  could  not  be  composed,  and  in  a  composite 
system,  every  variable  that  was  not  input  from  the  environment  was  essentially  “owned” 
by  one  of  the  component  interfaces,  which  was  the  only  one  allowed  to  modify  its  value. 

In  sociable  interface  modules,  we  can  leverage  the  presence  of  actions  in  order  to 
achieve  a  more  general  setting,  in  which  variables  can  be  modified  by  more  than  one 
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(a)  U\:  User  1 


(b)  P:  Printer. 


Fig.  5.  Informal  depiction  of  the  user  process  and  printer  interface  modules. 


module.  Informally,  the  model  is  as  follows.  With  each  action,  we  associate  a  set  of 
variables  that  can  be  modified  by  the  action,  as  well  as  an  output  and  an  input  transition 
relation  that  describe  the  ways  in  which  the  variables  can  be  modified  when  the  com¬ 
ponent,  or  its  environment,  output  the  action.  When  the  Output  player  takes  an  action 
a ,  the  output  transition  relation  associated  with  a  specifies  how  the  player  can  update 
the  variables  associated  with  a.  Symmetrically,  when  the  Input  player  takes  an  action 
a ,  the  input  transition  relation  associated  with  a  specifies  what  changes  to  the  variables 
associated  with  a  can  be  accepted  by  the  module. 

When  modules  are  composed,  actions  synchronize  in  the  same  way  as  they  do  in 
sociable  interface  automata.  When  an  output  event  a !  of  module  M  synchronizes  with  an 
input  event  a?  of  module  N,  we  must  check  that  all  variable  updates  that  can  accompany 
a !  from  M  are  acceptable  to  N,  that  is,  that  the  output  transition  relation  associated  with 
a  in  M  respects  the  constraints  specified  by  the  input  transition  relation  associated  with 
a  in  N .  Empty  transition  relations  are  used  to  rule  out  the  possibility  of  taking  an  action 
as  output  or  input. 

3.2  An  Example:  Modeling  a  Print  Server 

We  illustrate  the  main  features  of  sociable  interface  modules  through  a  very  simple  ex¬ 
ample:  a  model  of  a  shared  print  server.  The  model  consists  of  modules  representing 
the  print  server,  as  well  as  user  processes  that  communicate  with  the  server  to  print 
jobs.  The  modules  composing  this  example  are  depicted  in  an  intuitive  fashion  in  Fig¬ 
ure  5;  the  actual  input  to  the  tool  TIC  for  this  model  is  given  in  Figure  6,  and  it  will  be 
described  later. 

The  user  module  U\  (Figure  5(a))  communicates  via  two  actions:  an  action  print, 
whose  output  represents  a  print  request,  and  an  action  ack,  whose  input  represents  an 
acknowledgment.  When  generating  print  as  an  output,  U\  updates  the  global  variables 
user  and  size ,  which  indicate  the  user  who  issued  the  request,  and  the  size  of  the  request. 
The  print  server  P  (Figure  5(b))  synchronizes  on  ack  and  print ,  and  also  updates  a  global 
state  variable  busy ,  indicating  whether  the  printer  is  busy.  To  ensure  compatibility,  the 
user  module  checks  that  busy  =  F  before  printing.  In  addition,  to  ensure  compatibility 
in  presence  of  multiple  user  modules,  the  user  module  ignores  inputs  ack  when  idle 


(s  =  0),  as  these  acknowledgments  are  directed  to  other  users,  and  ignores  all  inputs 
print ,  as  these  correspond  to  input  requests  from  other  users. 

3.3  Definitions 

We  assume  a  fixed  set  V  of  variables.  All  variables  in  V  are  interpreted  over  a  given 
domain  <2).  Given  fCf,a  state  over  V  is  a  mapping  s  :  V  — *  £>  that  associates  with 
each  x  £  V  a  value  s(x)  £  ff).  For  a  set  of  variables  U  C  V,  and  a  state  s  £  [[V]],  the 
restriction  of  s  to  U  is  a  state  t  £  [[f/]]  denoted  as  s[U}.  For  two  disjoint  sets  of  variables 
V\  and  Vj,  and  two  states  si  £  [[Vj]]  and  S2  £  [[V2]] ,  the  operation  (si  o  S2)  composes  the 
two  states  resulting  in  a  new  state  s  =  si  0S2  £  [[Vj  U  Vj]],  such  that  s(x)  =  .sq  ( x )  for  all 
x  £V\  and  s(x)  =  S2 (x)  for  all  x  e  Vj. 

Our  formal  model  with  variables  is  called  a  sociable  interface  module.  It  is  con¬ 
venient  to  define  sociable  interface  modules  with  respect  to  a  predicate  representation. 
Given  a  set  V  of  variables,  we  denote  by  Preds(V)  the  set  of  first-order  predicate  for¬ 
mulas  with  free  variables  in  V;  we  assume  that  these  predicates  are  written  in  some 
specified  first-order  language  with  interpreted  function  symbols  and  predicates;  in  our 
tool,  the  language  contains  some  arithmetic  operators,  relational  symbols,  and  boolean 
connectives.  Given  a  set  of  variables  V,  we  let  V'  =  {x'  \  x  £  V }  be  the  set  consisting  of 
primed  versions  of  variables  in  V.  A  variable  x'  £  V'  represents  the  next  value  of  x  £  V. 
Given  a  formula  y/  £  Preds(V)  and  a  state  s  £  [[V]],  we  write  s  |=  if/  if  the  predicate  for¬ 
mula  y/  is  true  when  its  free  variables  are  interpreted  as  specified  by  s.  Given  a  formula 
p  £  Preds(V  U  V')  and  two  states  s,s'  £  [[V]],  we  write  ( s,s ')  ]=  p  if  the  formula  p  holds 
when  its  free  variables  x  £  V  are  interpreted  as  s(x),  and  its  free  variables  x'  £  V'  are 
interpreted  as  s'  (x) .  Given  a  set  U  of  variables,  we  define  the  formula: 

UnchgdiU )  =  f\  (x'  =  x) . 
xeu 

which  states  that  the  variables  in  U  do  not  change  their  value  in  a  transition.  Given  a 
predicate  y/  £  Preds(V),  we  denote  by  yf'  the  predicate  obtained  by  substituting  x  with 
x'  in  yf,  for  all  x  £V. 

With  these  definitions,  we  can  define  sociable  interface  modules  as  follows. 

Definition  15  (Sociable  Interface  Module).  A  sociable  interface  module  ( module ,  for 
short)  is  a  tuple  M  =  (Act,VG ,VL ,VH ,W, pIL , p/G , p° ,  yf1 ,  y/° ),  where: 

-  Act  is  a  set  of  actions. 

-  VG  is  a  set  of  global  variables,  VL  is  a  set  of  local  variables,  and  VH  C  VG  is 
a  set  of  history  variables.  We  require  VL  fl  VG  =  0.  We  set  Val1  =  VL  U  VG  and 
V=VLUVH. 

-  W  :  Act  ^  Val1  associates  with  each  a  £  Act  the  set  of  variables  W  (a)  C  V a11  that 
can  be  modified  by  a;  we  require  VL  C  W (a). 

-  For  each  a  £  Act,  the  predicate  pIL(a)  £  Preds(V aI1  U  (Vally)  is  the  input  local 
transition  predicate  for  a.  We  require  this  transition  predicate  to  be  deterministic 
w.r.t.  variables  in  VL,  that  is,  for  all  a  £  Act,  all  s  £  ][Fal1]],  and  all  t  £  [[(VG)/]],  there 
is  a  unique  u  £  [[(Vi)/]]  such  that  sotou  |=  pIL{a). 


-  For  each  a  £  Act,  the  predicate  pIG(a)  £  Preds(Val1  U  ( VG )')  is  the  input  global 
transition  predicate  for  a. 

-  For  each  a  £  Act,  the  predicate  p°(a )  £  Preds(Vail  UW  (a)')  is  the  output  transition 
predicate  for  a. 

-  y/1  £  Predsly3^)  is  the  input  invariant  predicate. 

-  \j/°  £  Predsiy al!)  is  the  output  invariant  predicate. 

A  state  is  a  value  assignment  to  Val1;  we  denote  the  set  of  states  of  the  module  by 
S  =  [[Val1]].  The  invariant  predicates  define  invariants 

(p1  =  {s  £  S  |  s  1=  y/},  (p°  =  {s  £  S  |  s  |=  y/°}. 

As  a  shorthand,  for  all  a  £  Act  we  let  p!(a)  =  plL(a )  A  pIG(a),  and  we  define 

pI(a)  =  pI(a)A(VIy 

p°(a)  =  p°{a)  A  (y°Y  A  Unchgd(Van  \  W(a)). 


Notice  that  p\a)  and  p°(a)  are  predicates  over  Val1  U  (Val1)'. 

In  our  model,  each  module  owns  a  set  of  local  variables,  that  describe  the  internal 
state  of  a  component.  We  distinguish  a  set  VH  of  history  variables,  and  a  set  VG\VH  of 
history-free  variables.  A  module  must  be  aware  of  all  actions  that  can  modify  its  history 
variables  (see,  in  the  following,  the  non-interference  condition  in  Definition  19).  On 
the  other  hand,  history-free  variables  can  be  modified  by  environment  actions  that  are 
not  known  to  the  module.  The  distinction  between  the  history  and  history-free  global 
variables  is  thus  used  to  limit  the  amount  of  actions  a  module  should  include;  this  point 
will  be  clarified  when  we  will  discuss  module  composability. 

The  definitions  of  the  input  and  output  transition  relations  are  similar  to  those  of 
Section  2.  We  require  the  input  transition  relation  to  be  deterministic  on  local  variables. 
This  assumption  corresponds  to  the  assumption,  in  the  model  without  variables,  that 
input  transitions  are  deterministic.  In  fact,  we  will  see  that  when  an  output  and  an  input 
transitions  synchronize,  it  is  the  output  transition  that  selects  the  next  value  of  the  global 
variables,  and  the  input  transition  is  used  only  to  determine  the  next  value  of  the  local 
variables. 


In  the  remainder  of  this  section  we  consider  a  fixed  module  M  = 
(A ctM ■  Vy  ■  V‘M ,  Viy ,  Wm ,  p1^ ,  py  ,Pm,  Ym,  Ym)’  and  we  set  Vm  =  =  U 

V(vj,  and  correspondingly  for  the  shorthands  p(f  and  p^. 


Definition  16  (Set  of  States).  The  set  of  states  of  the  sociable  interface  module  M  is 
given  by  SM  =  [[V^]}. 

The  sets  of  moves  for  players  Input  and  Output  are  defined  as  follows.  Note  that,  when 
Input  plays  the  move  Aq,  Input  can  also  choose  a  new  assignment  to  the  history-free 
variables.  This  models  the  fact  that  history-free  variables  can  be  modified  by  environ¬ 
ment  actions  that  are  not  known  to  the  module. 


Definition  17  (Moves).  The  sets  r!(M,s)  and  r°(M .s)  of  Input  and  Output  moves  at 
s  G  Sm  are  defined  as  follows: 


r'(M,s)  ={A0}  x  {/  G  [[<]]  |  s'[Vm]=s[Vm}} U 

{(a, s')  eActM  x  [[V^11]]  |  (s, s')  |=  p^a)} 

r°(M,s)  ={A0}U{(a/)  £ActM  x  [[V^1]]  |  (s,s')  \=p°(a)}. 

The  outcome  of  the  moves  are  as  follows. 

Definition  18  (Move  Outcome).  For  all  states  s  G  Sm  and  moves  m1  G  F7(M,s)  and 
m°  G  r°(M,s),  the  outcome  8(M,s,mI ,m°)  C  Sm  of  playing  m1  and  m°  at  s  can  be 
defined  as  follows. 


S{M,s,  (Aq,s'),A0)  =  {s'},  8(M,s,  ( A0,s'),(af '))  =  {s',/'}, 

8(M,s,(a,s'),A0)  =  {s'},  8(M,s,(a,s'),(b,tt))  =  {s'/}. 

The  definitions  of  run,  strategy,  strategy  outcome,  winning  state  and  well-formedness 
are  similar  to  the  ones  given  in  Section  2. 

3.4  The  Printer  Example,  Continued 

Figure  6  presents  our  print-server  example,  encoded  in  the  actual  input  language  of  the 
tool  TIC.  The  system  consists  of  the  global  variables  busy ,  size,  user,  of  a  printer  mod¬ 
ule,  and  of  two  user  modules.  In  each  module,  we  give  the  set  of  history-free  variables 
(called  stateless  in  the  language  of  the  tool);  the  set  of  global  variables  of  the  module  is 
simply  inferred  as  the  set  of  global  variables  that  appear  anywhere  in  the  module. 

The  module  Printer  communicates  via  two  actions,  ack  and  print.  The  transition 
predicates  of  these  actions  are  specified  using  a  guarded-commands  syntax,  similar  to 
[4, 1],  Each  guarded  command  has  the  form  guard  =>■  command,  where  guard  and  com¬ 
mand  are  formulas  written  over  the  set  of  primed  and  unprimed  variables.  A  guarded 
command  guard  =>■  command  can  be  taken  when  its  guard  is  true;  when  taken,  com¬ 
mand  specify  how  the  variables  are  updated.  For  instance,  the  output  transition  print 
in  module  Userl  can  be  taken  when  s  =  0  and  busy  =  F,  and  it  leads  to  a  state  where 
,y  =  1  and  user  =  1.  The  value  of  size  in  the  destination  state  is  nondeterministic. 

When  specifying  sociable  interface  modules  in  the  tool  TIC,  we  use  several  short¬ 
hands  to  make  the  notation  more  pleasant: 

-  When  we  do  not  specify  the  input  or  output  transition  relation  for  an  action,  the 
omitted  transition  relations  are  assumed  to  be  false.  For  example,  the  action  ack 
has  no  input  transition  relation  in  the  printer:  this  specifies  that  no  other  module 
should  be  able  to  emit  it.  Similarly,  the  action  ack  has  no  output  transition  relation 
in  the  user  modules,  specifying  that  modules  do  not  generate  it. 

-  When  we  specify  a  transition  relation  via  an  empty  guarded  command,  the  guard  is 
assumed  to  be  always  true,  and  the  command  is  as  follows: 

•  Output  transition  relations,  and  local  part  of  input  transitions:  no  variables  are 
changed. 


var  busy:  bool;  //  global  variable  indicating  a  printer  busy 

var  size:  [0 . . 10] ;  //  size  of  the  print  job 

var  user:  [0 . . 5] ;  //  user  who  requested  the  job 

module  Printer: 

output  ack  {  busy  ==>  not  busy’ ;  } 

//  ack?  is  not  allowed 

input  print  {  global:  not  busy  ==>  busy’;  } 
endmodule 


module  Userl: 
var  s  :  [0 .  .  1]  ; 

stateless  size,  user; 

output  print  {  s  =  0  t  not  busy  ==> 

s’  =  1  &  user’  =  1  &  nondet  size’;  } 
input  print  {  }  //  print?  is  allowed  and  ignored 

input  ack  {  local:  s  =  1  ==>  s’  :=  0; 

else  s  =  0  ==>  ;  }  //  ignore  ack?  when  s=0 


endmodule 


module  User2 : 
var  s  :  [0 .  .  1]  ; 

stateless  size,  user; 

output  print  {  s  =  0  &  not  busy  ==> 

s’  =  1  &  user’  =2  &  nondet  size’;  } 
input  print  {  }  //  print?  is  allowed  and  ignored 

input  ack  {  local:  s  =  1  ==>  s’  :=  0; 

else  s  =  0  ==>  ;  }  //  ignore  ack?  when  s=0 


endmodule 


Fig.  6.  TIC  input  modeling  a  simple  print  server. 


•  Global  part  of  input  transitions:  the  transition  relation  is  considered  to  be  true, 
so  that  all  state  changes  are  accepted. 

-  In  a  guarded  command  guard  =>  command ,  when  guard  is  missing,  it  is  assumed 
to  be  true.  If  command  is  missing,  then: 

•  Output  transitions,  and  local  part  of  input  transitions:  no  variables  are 
changed. 

•  Global  part  of  input  transitions:  the  transition  relation  is  considered  to  be  true, 
so  that  all  state  changes  are  accepted. 

-  In  output  transitions,  and  in  the  local  part  of  input  transitions,  variables  that  are 
not  mentioned  primed  in  the  command  portion  of  a  guarded  command  guard  =>■ 
command  do  not  change  their  value. 

As  a  more  elaborate  example,  in  Figure  7  we  present  the  code  of  a  print  server  that 
can  accept  or  reject  jobs,  depending  on  their  length. 


3.5  Compatibility  and  Composition 


We  now  describe  the  composition  of  two  modules.  Due  to  the  presence  of  variables, 
this  process  is  more  involved  than  the  one  presented  in  Section  2. 

The  composition  of  two  modules  M\  and  Mi  is  defined  in  four  steps,  in  a  similar 
way  as  stated  in  [9],  First,  we  define  when  M\  and  Mi  are  composable,  and  in  the 
affirmative  case,  we  define  their  product  M\  0  Mi.  On  the  resulting  product  module,  we 
identify  a  set  of  bad  states:  these  are  the  states  where  M i  (resp.  Mi)  can  produce  an 
output  that  is  not  accepted  by  Mi  (resp.  M\).  Finally,  the  composition  M\ \\Mi  of  M\  and 
Mi  is  obtained  from  the  product  M\  0  M2  by  strengthening  the  input  transition  relations 
of  M 1  0M2  in  such  a  way  that  all  bad  states  are  avoided. 

In  the  following,  we  consider  two  modules  M\  and  Mi,  where  M,  = 
(Acti,Vj},ViL,VfI,Wi,pfL,pIiG,p-:>,\l/j,\l/-:>),  for  i  =  1,2,  and  we  let  V,-  =  Vlp  U  and 
y.a11 :  y.LuV-G. 


We  say  that  two  modules  M\  and  Mi  are  composable  if  they  have  disjoint  sets  of 
local  variables,  and  if  they  satisfy  a  non-interference  condition,  stating  that  if  an  action 
of  a  module  can  modify  a  state  variable  of  the  other,  then  the  action  is  shared.  This 
condition  ensures  that  the  set  of  actions  of  a  module  includes  all  the  actions  that  can 
modify  its  state  variables.  This  condition  is  essential  for  modular  reasoning.  It  ensures 
that  composition  does  not  add  behaviors:  all  changes  in  the  state  of  M 1  caused  by  mod¬ 
ules  with  which  M\  is  composable  can  be  already  explained  by  the  input  transitions 
associated  with  actions  of  M\ . 


Definition  19  (Composability).  Two  sociable  interface  modules  M\  and  Mi  are  com¬ 
posable  iff  Vl{  n  Vf  =  0  and  if  the  following  non-interference  conditions  hold: 

Va  £  Acti .  Wi  ( a )  0  Vj  0  =>  a  £  Act \ 

\/a  £  Act  1 .  Wi(a)lTV2  ^0  =4>  a  £  Act2  • 


The  non-interference  condition  is  the  main  justification  for  distinguishing  between 
the  sets  of  history  and  history-free  variables.  The  non-interference  condition  states  that 


var  busy:  bool;  //  global  variable  indicating  a  printer  busy 

var  size:  [0 . . 10] ;  //  size  of  the  print  job 

var  user:  [0 . . 5] ;  //  user  who  requested  the  job 

module  Printer: 

output  ack  {  busy  &  size  <  5  ==>  not  busy’;  }  //  accept  if  size  <  5 

//  ack?  is  not  allowed 

output  nack  {  busy  &  size  >  4  ==>  not  busy’ ;  }  //  reject  if  size  >  4 

//  nack?  is  not  allowed 

input  print  {  global:  not  busy  ==>  busy’;  } 
endmodule 

module  Userl: 
var  s  :  [0 .  .  1]  ; 

stateless  size,  user; 


output  print  {  s  =  0  t  not  busy  ==> 

s’  =  1  &  user’  =  1  &  nondet  size’;  } 
input  print  {  }  //  print?  is  allowed  and  ignored 

input  ack  {  local :  s  =  1  ==>  s’  : =  0 ; 

else  s  =  0  ==>  ;  }  //  ignore  ack?  when  s=0 


input  nack  {  local :  s 
else  s 


endmodule 


1  ==>  s’  :=  0; 

0  ==>  ;  }  //  ignore  nack?  when  s=0 


module  User2 : 
var  s  :  [0 .  .  1]  ; 

stateless  size,  user; 


output  print  {  s  =  0  &  not  busy  ==> 

s’  =  1  &  user’  =  2  &  nondet  size’;  } 
input  print  {  }  //  print?  is  allowed  and  ignored 


input 
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endmodule 


Fig.  7.  TIC  input  modeling  a  print  server  that  rejects  large  jobs. 


a  module  should  know  all  actions  of  other  modules  that  modify  its  history  variables.  If 
we  dropped  the  distinction,  requiring  that  a  module  knows  all  actions  of  other  modules 
that  can  change  any  of  its  variables  (history  or  history-free),  we  could  greatly  increase 
the  number  of  actions  that  must  be  known  to  the  module. 

As  an  example,  consider  a  set  of  modules  {A/, } /e { l . .  l oo }  ■  Each  module  has  an  action 
at  whose  output  transition  relation  sets  index  to  i,  and  x  to  some  content,  where  index  and 
x  are  global  variables  shared  among  all  N\ , . . . ,  (Vioo-  If  module  Nj  does  not  need  to  keep 
track  of  the  value  of  index  and  x,  as  these  variables  are  used  as  outputs  only,  then  we  can 
let  index  0  Ty.  and  x  gL  V y,  even  though  of  course  index, x  £  Vg .  The  non-interference 
condition  for  Nj,  stated  in  terms  of  Vy,  will  not  require  Nj  to  know  about  a;-  for  i  g  j. 
This  keeps  the  model  of  Nj  simple  and  concise  and,  even  more  importantly,  enables  us 
to  model  Nj  before  we  know  exactly  how  many  other  modules  there  are  that  can  modify 
index  and  x.  Dropping  the  distinction  between  Vy  and  Vy\  on  the  other  hand,  would 
force  each  A,-  to  have  all  the  actions  a\, . . .  ,aioo  in  its  set  of  actions,  greatly  complicating 
the  model,  and  forcing  us  to  know  in  advance  how  many  components  there  are,  before 
each  of  the  components  can  be  modeled.  Similarly,  if  a  module  reads  a  variable  x,  but 
does  not  need  to  know  how  and  when  the  value  of  x  is  changed,  then  the  variable  x  can 
be  declared  to  be  history-free,  so  that  the  module  does  not  have  to  know  all  the  actions 
that  can  modify  x.  Hence,  the  distinction  between  history  and  history-free  variables  is 
at  the  heart  of  our  “sociable”  approach  to  compositional  modeling. 

We  define  the  product  of  two  sociable  interface  modules  M\  and  M2  as  follows. 

Definition  20  (Product).  Assume  that  Mi  and  M2  are  composable.  The  product  M\  0 
M2  is  the  interface  Mn  =  (Acti2,Vg,Vg,Vg, Wi2,Pi2,Pn  >Pi2>  Yui  Y12)’  defined  as 
follows. 


-  Act  12  =  Act\  \JActi ■ 

-  Vg  =  VG  U  Vg;  V(2  =  v[  U  Vk-  Vg2  =  Vg  U  Vg; 

W\(a)UW2(a)  for  a  £  Shared  (Mi,  M2) 

Wj(a)  for  a  £  Actj\Act2^\,  i  £ 

-  ¥12  =  V[  A  V4;  W12  =  V?  A  ¥?. 

-  For  a  £  Shared (M\  ,M2),  we  let: 

Pl2(a)  = 

/ pf  (a)  A  pgia)  A  Unchgd(Wn{a)  \  (W\  (a)  U  V2  ))  \ 

= 

\pg(a)  Ap[L(a)  A  Unchgd{W\2{a)  \  {W2(a)  yjV\;))  / 


yd^yauyy; 


all 


/all 


{1,2}. 


Pn(a)  =P\L(a)  Apf(a) 
Pn(a)  =PiG(a)Ap{G(a). 


-  For  i  £  {1,2}  and  a  £  Actj  \Acti,-i  we  let: 

Pn(a)  =  pf)(a) 

Pn(a)  =  PiL(a)  A  UnchgdiV f_t) 

P12  («)  =  P/G(«) A  Unchgd{Vg_i). 

We  have  the  following  result. 

Theorem  4.  Product  between  modules  is  a  commutative  and  associative  operation. 
Similarly  to  Definition  12,  we  identify  a  set  of  locally  incompatible  states  of  the  product 

Definition  21  (Local  Compatibility).  Given  s  £  [[Vp1]],  we  say  that  s  is  good  iff  it 
satisfies  the  predicate  good(M\  .M2),  defined  as  follows: 

good  (Mi,  M2)  = 

{V(V$)' \{p?(a)AUnchgd(V?\Wi(a)))  =►  pf  (a))  ^ 

=  A 

aeShared(MiM 2)  ^ V(V*)' .  ((pf  (a)  A  Unchgd(VG  \  W2(a)))  =►  p[G(a :))  y 

Using  this  condition,  the  composition  Mi  ||M2  is  obtained  from  Mi®M2  by  restricting 
the  input  invariant  of  Mp  to  the  set  of  well-formed  states  from  where  input  has  a  strat¬ 
egy  to  always  stay  in  the  good  states  good(M\  ,M2),  in  analogy  with  Definition  13. 

Theorem  5.  Composition  between  modules  is  a  commutative  and  associative  opera¬ 
tion. 


4  Refinement 


We  wish  to  define  a  refinement  relation  between  modules,  such  that  when  M\  re¬ 
fines  M2,  Mi  can  be  used  as  a  replacement  for  M2  in  any  context.  First,  some 
conditions  should  hold  on  the  set  of  variables  that  the  modules  manipulate.  In  the 


following.  Mi  and  Mi  are  two  modules  in  normal  form.  For  i  £  {1,2},  let  M,  = 
(Actt , VG , , Vf1 ,  Wi , pjL , pjG , pf ,  wU  W?)>  V‘  =  V,HCV,L  and  Si  =  [[V/]].  The  sets  Act;, 
VG,  V/1 ,  and  IV,  jointly  define  the  signature  of  a  module  M\. 


Definition  22  (Signature).  The  signature  Sign(Mj)  of  a  module  M,  =  (Act,.  VG .  V-L, 
V,H,Wi,pjL,plG,p°,  y/j,  iv°),  is  the  tuple  (Act^V^Vf1  ,Wt). 


The  following  result  shows  that  signature  equality  preserves  composability.  It  can  be 
proved  by  inspecting  Definition  19. 


Theorem  6.  Let  N\  ,1V2,  and  IV3  be  three  modules,  such  that  the  Sign(N\ )  =  Sign(Ni), 
and  N2  and  /V3  are  composable.  For  i  £  {1,2,3},  let  V['  be  the  set  of  local  variables  of 
Nj.  IfVy  D  =  0,  then  Ni  and  /V3  are  composable. 


To  replace  M2,  M\  should  also  behave  like  it,  from  the  point  of  view  of  the  environment. 
As  usual  in  a  game-theoretic  setting  such  as  ours,  this  constraint  is  captured  by  alter¬ 
nating  simulation  [2],  Intuitively,  M\  must  be  willing  to  accept  at  least  all  the  inputs 
that  Mt  accepts,  and  it  should  emit  a  subset  of  the  outputs  emitted  by  M2. 

Definition  23  (Alternating  Simulation).  Assume  that  Sign(M\ )  =  Sign  (M2).  A  rela¬ 
tion  A  C  Si  X  S2  is  an  alternating  simulation  iff.?  A  t  implies: 

1.  S[V,G]  =f[Vf  ]; 

2.  for  all  a  £  Act\  and  for  all  t'  £  S2  such  that  {t,t')  \=  Pi{a)  there  exists  s'  £  S 1  such 
that  (s,s')  \=  p[(a )  and  .?'  A  t'\ 

3.  for  all  a  £  Act\  and  for  all  s'  £  S 1  such  that  ( s,s ')  \=  p°(a)  there  exists  t'  £  S2  such 
that  (t,tr)  1=  p2{a)  and  s'  A  t' . 

We  say  that  s  is  similar  to  t,  and  we  write  s  Q  t,  if  there  exists  an  alternating  simulation 
A  such  that  ,v  A  t.  Similarity  is  itself  a  simulation  (the  coarsest  one).  For  M 1  to  refine 
M2,  M\  and  M2  should  have  the  same  signature,  and  each  well-formed  state  of  M2  must 
be  similar  to  some  well-formed  state  of  M\ . 

Definition  24  (Refinement).  We  say  that  Mi  refines  M2  iff  (i)  Sign(M\)  =  Sign(M2), 
and  ( ii)  for  all  f  |=  i/4a  iff®  there  is  s  |=  t//[  A  i//]9  such  that  ?□. 

Theorem  7.  Let  Ni  ,N2,  and  A3  be  three  modules,  such  that  N\  refines  N2,  and  N2  and 
N2  are  compatible.  For  i  £  {1,2,3},  let  be  the  set  of  local  variables  ofNj.  IfV\  IT 
V3l  =  0,  then  N\  and  IV3  are  compatible. 

We  now  introduce  the  related  concept  of  bisimilarity.  Bisimilarity  between  two  modules 
captures  the  intuitive  concept  that  the  environment  cannot  distinguish  the  two  modules. 

Definition  25  (Alternating  Bisimulation).  Assume  that  Sign(M\ )  =  Sign(M2).  A  re¬ 
lation  «C  Si  x  S2  is  an  alternating  bisimulation  iff  it  is  a  symmetrical  alternating  sim¬ 
ulation. 

We  say  that  s  and  t  are  bisimilar,  and  we  write  ,v  =  t,  if  there  exists  an  alternating 
bisimulation  «  such  that  s  « t . 

Definition  26  (Bisimilarity).  We  say  that  Mi  and  Mi  are  bisimilar  iff  (i)  Sign(M\ )  = 
Sign{M2),  and  (ii)  for  all  t  |=  y/}  A  I j/%  there  is  s  |=  t//{  A  i//)0  such  that  s  =  t,  and  for  all 
s  {=  i//f  A  v/j0  there  is  t  |=  A  yt?  such  that  s  =  t . 

Theorem  8.  Let  N 1  ,N2,  and  N2  be  three  modules,  such  that  N\  is  bisimilar  to  N2.  For 
i  £  {1,2,3},  let  be  the  set  of  local  variables  ofNj.  If  V'y  fl  V3  =  0  andVf  C\V3  =  0, 
then  N\  and  A3  are  compatible  ijfN2  and  A3  are  compatible. 


5  Symbolic  Implementation 


In  this  section,  we  examine  the  problem  of  efficiently  implementing  the  following  op¬ 
erations:  (i)  module  composition,  (ii)  verification  of  safety  properties  of  modules  (such 
as  well-formedness),  and  (in)  refinement  and  bisimilarity  checking  between  modules. 

Consider  the  module  M  =  {ActM-,V^,V^,V^,WM,pM  ,pffi  ,Pm,Ym’Ym)’  and  set 

T/all  _  t  jL  i  |  i/G 
VM  —  VMU  VM- 

A  well-established  technique  for  efficiently  implementing  finite  transition  systems 
is  based  on  MDDs  [12, 14],  MDDs  are  graph-like  data  structures  that  allow  us  to  repre¬ 
sent  and  manipulate  functions  of  the  type  A  — ►  {T,F},  for  a  finite  set  A  (i.e.  predicates 
over  A).  Therefore,  we  assume  that  the  variable  domain  S’  is  finite,  and  we  represent  the 
predicates  p1^.  pj^,  p$,  Ym-  and  Ym  as  MDDs.  We  now  show  that  all  the  operations 
involved  in  computing  the  composition  of  modules,  checking  their  well-formedness, 
checking  safety  properties,  and  checking  refinement  are  computable  on  MDDs. 


5.1  Safety  Games 

A  basic  operation  on  modules  is  computing  the  set  of  winning  states  for  a  player  p  £ 
{/,  0}  w.r.t.  a  safety  goal,  that  is  Winp(M ,  Dtp),  for  some  set  <p  C  [[V^1]].  The  operations 
of  checking  well-formedness,  putting  a  module  in  normal  form,  and  computing  the 
composition  of  two  modules,  are  all  reducible  to  solving  safety  games. 

By  abuse  of  notation,  we  denote  by  Winp(M,  Dtp)  both  the  set  of  states  it  denotes, 
and  its  characteristic  function,  which  is  a  predicate  over  V'f^ . 

It  is  well  known  that  such  set  of  winning  states  can  be  characterized  as  a  fix-point 
of  an  equation  involving  the  so-called  controllable  predecessors  operators.  For  a  player 
p  £  {1,0}  and  a  predicate  X  £  Preds(V ^*),  the  operator  Cprep(X)  returns  the  set  of 
states  from  which  player  p  can  force  the  game  into  X  in  one  step,  regardless  of  the 
opponent’s  moves.  Formally,  we  have  the  following  definition. 

Definition  27  (Controllable  Predecessor  Operator).  For  a  predicate  X  £  PredsiV^), 
we  have: 

Cpre1  (X)  =  3m1  G  T1  (M,s) .Mm°  G  r°(M,s)  .Mt  G  8(M,s,mI ,m°)  .t  \=  X 
Cpre°(X)  =  3m°  G  r°(M,s)  .Mm1  G  r!(M,s)  .Vf  G  8(M,s,mI ,m°)  .t  \=  X. 

Intuitively,  Cpre1  (X)  (resp ,Cpre°(X))  holds  true  for  the  states  from  which  the  Input 
(resp.  Output)  player  has  a  move  that  leads  to  X  for  each  possible  counter-move  of  the 
Output  (resp.  Input)  player.  For  all  (p  G  Preds(V^),  we  have: 

Win\M,  Dtp)  =  VX.  [<p  A  Cpre1  (X)] 

Win0(M,D(p)  =  vX.  [(p  ACpre°(X)}, 

where  vX  ,f(X)  denotes  the  greatest  fixpoint  of  the  operator  /.  Since  Cpre1}-)  is  mono¬ 
tonic,  the  above  fixpoints  exist  and  can  be  computed  by  Picard  iteration: 

Xi+l=(p/\Cpre\Xi),  ...  Xn=Xn+l  =  Win1  (M.  Dtp).  (1) 


Xo  =  <P , 


We  now  show  how  to  compute  Cpre1  (X)  starting  from  the  MDD  representation  of  M. 
Considering  Definition  18,  in  order  for  a  state  ,v  to  satisfy  Cpre1  (X),  two  conditions 
must  hold.  First,  every  output  transition  should  lead  to  X.  Second,  either  s  |=  X,  in 
which  case  Input  can  play  (Aq,s),  or  there  must  be  an  input  transition  that  leads  to  X. 
This  observation  allows  us  to  express  Cpre1  (X)  as  follows: 

Cpre1  (X)  =  \/Pre°(X)  A  3 Pre^X), 


where 

XPre°(X)=  /\  V(<)'.(p£(a)^X') 

a^zA-Ct^i 

3  Pre\x)  =XV  (3(<)'  .X'  A  Unchgd(V”  U  v£))  V  \/  3«)'  •  (Pm(«)  AX'). 

t i(zActhj 

Since  boolean  operations  and  quantifications  of  variables  are  computable  on  MDDs,  the 
operators  above  are  computable.  In  a  dual  fashion,  Cpre°(X )  can  be  computed  from  the 
non-game  operators  VP  re1  (•)  and  3  Pre°(-). 

We  can  improve  the  efficiency  of  computing  Win1  (M.  Dtp),  by  observing  that, 
since  (1)  is  a  decreasing  sequence,  it  holds  that  vX.  [<p  A  Cpre\X)\  =  vX.  [<p  AX  A 
Cpre1  (X)].  Since  X  A  Cpre'(X)  =  X  A  MPre°{X),  we  obtain 

Win\M,D(p )  =  vX.  [(p  AX  AXPre0  (X)\  =  vX.  [<p  A \/Pre°(X)\. 

In  conclusion,  we  can  then  compute  Win1  by  iterating  \/Pre°(-)  instead  of 

the  more  complicated  Cpre!(-).  A  similar  argument  holds  for  the  computation  of 
Win°{M,  □<?>). 

5.2  Composition 

By  inspecting  Definition  20,  it  is  clear  that  computing  the  product  of  two  modules 
M\  and  M2  only  involves  simple  boolean  operations  on  the  predicates  that  define  the 
modules.  Such  operations  are  computable  on  MDDs. 

To  obtain  the  composition  M\\\M2,  according  to  Definition  13,  the  in¬ 
put  invariant  y/[9  of  the  product  must  be  conjoined  with  the  predicate 
Win1  (M\  <g>M2,0(y/,]2  Agood(Mi,M2)).  To  compute  the  above  winning  set,  we  first 
compute  the  predicate  good(M\  ,Mt)  following  Definition  21,  and  then  solve  the  safety 
game  as  explained  in  Section  5.1. 


5.3  Refinement 


Let  M\  and  M2  be  two  modules  in  normal  form,  such  that  Sign(M{)  =  Sign(M2). 
For  i  G  {1,2},  let  M,  =  (Act,VG,  Vf,VH,  W,pjL,pjG,p^ ,  V'/,  V?),  K'3"  =  yG  UVf  and 
Si  =  P}-311]]  ■  Assume  for  simplicity  that  VG  ft  V-f  =  0.  We  wish  to  compute  the  coarsest 
alternating  simulation  L_  between  .Sj  and  .S-2.  Consider  the  predicate  1//-  over  the  set  of 


variables  Vja11  U  V0a11,  defined  as  the  greatest  fixpoint  of  the  operator  SimPre(-),  defined 
as  follows.  For  all  X  £  Preds(Vfl  UFf11),  we  have 

SimPre(X)=X  A  /\  V{vf)' .  3(Vft' .  (pf(a) 

aeAct 

a  a 

aeAct 

The  operator  SimPre(-),  and  consequently  its  fixpoint  i//-,  can  be  computed  from  the 
MDD  representation  of  M\  and  Mj.  The  following  result  states  that  i/r-  can  be  used 
to  trivially  obtain  C.  The  result  can  be  proven  by  induction,  observing  that  SimPre(-) 
represents  conditions  2  and  3  of  Definition  23. 

Theorem  9.  Given  s  £  Si  and  t  £  Si,  sQt  iffs[VG]  =  r[VG]  and  s  ot  [Vf  ]  1=  Vfe- 
A  similar  algorithm  can  be  used  to  compute  the  coarsest  bisimulation  =. 

6  Comparison  with  Previous  Interface  Models 

The  sociable  interface  model  presented  in  this  paper  is  closely  related  to  the  I/O  Au¬ 
tomata  Model  (IOA)  of  [11]:  sociable  interfaces  synchronize  on  actions  and  use  vari¬ 
ables  to  encode  the  state  of  components.  However,  sociable  interfaces  diverge  from  I/O 
Automata  in  several  ways.  Unlike  I/O  Automata,  where  every  state  must  be  receptive  to 
every  possible  input  event,  sociable  interfaces  allow  states  to  forbid  some  input  events. 
By  not  accepting  certain  inputs,  sociable  interfaces  express  the  assumption  that  the  en¬ 
vironment  never  generates  these  inputs:  hence,  sociable  interfaces  (like  other  interface 
models)  model  both  the  output  behavior,  and  the  input  assumptions,  of  a  component. 
This  approach  implies  a  notion  of  composition  (based  on  synthesizing  the  weakest  en¬ 
vironment  assumptions  that  guarantee  compatibility)  which  is  not  present  in  the  I/O 
Automata  Model. 

Interface  models  are  the  subject  of  many  recent  works.  Previous  interface  models, 
such  as  interface  automata  [6, 8]  and  interface  modules  [7, 3]  were  based  on  either  ac¬ 
tions,  or  variables,  but  not  both.  Sociable  interfaces  do  not  break  new  ground  in  the 
conceptual  theory  of  interface  models.  However,  by  allowing  both  actions  and  vari¬ 
ables,  they  take  advantage  of  the  existing  models  and  try  to  avoid  their  deficiencies. 
The  rest  of  this  section  is  devoted  to  a  quick  presentation  of  existing  interface  models. 

Variable-based  interface  formalisms.  In  variable-based  interface  formalisms,  such  as 
the  formalisms  of  [7, 3],  communication  is  mediated  by  input  and  output  variables,  and 
the  system  evolves  in  synchronous  steps.  It  is  well  known  that  synchronous,  variable- 
based  models  can  also  encode  communication  via  actions  [1]:  the  generation  of  an 
output  al  is  translated  into  the  toggling  of  the  value  of  an  (output)  boolean  variable  xa, 
and  the  reception  of  an  input  a?  is  encoded  by  forcing  a  transition  to  occur  whenever  the 
(input)  variable  xa  is  toggled.  This  encoding  is  made  more  attractive  by  syntactic  sugar 
[  1  ] .  However,  this  encoding  prevents  the  modeling  of  many-to-one  and  many-to-many 
communication. 


Pi  (<0  AX') 

Pi  {a)  AX'). 


In  fact,  due  to  the  synchronous  nature  of  the  formalism,  a  variable  can  be  modified 
at  most  by  one  module:  if  two  modules  modified  it,  there  would  be  no  simple  way 
to  determine  its  updated  value.6  Since  the  generation  of  an  output  a!  is  modeled  by 
toggling  the  value  of  a  boolean  variable  xa,  this  limitation  indicates  that  an  output  action 
can  be  emitted  at  most  by  one  module.  As  a  consequence,  we  cannot  write  modules  that 
can  accept  inputs  from  multiple  sources:  every  module  must  know  precisely  which  other 
modules  can  provide  inputs  to  it,  so  that  distinct  communication  actions  can  be  used. 
The  advance  knowledge  of  the  modules  involved  in  communication  hampers  module 
re-use. 

Action-based  interface  formalisms.  Action-based  interfaces,  such  as  the  models  of  [6, 
5, 8],  enable  a  natural  encoding  of  asynchronous  communication.  In  previous  proposal, 
however,  two  interfaces  could  be  composed  only  if  they  did  not  share  output  actions  — 
again  ruling  out  many-to-one  communication. 

Furthermore,  previous  action-based  formalisms  lacked  a  notion  of  global  variables 
which  are  visible  to  all  the  modules  of  a  system.  Such  global  variables  are  a  very  pow¬ 
erful  and  versatile  modeling  paradigm,  providing  a  notion  of  global,  shared  state.  Mim¬ 
icking  global  variables  in  purely  action-based  models  is  rather  inconvenient:  it  requires 
encapsulating  every  global  variable  by  a  module,  whose  state  corresponds  to  the  value 
of  the  variable.  Read  and  write  accesses  to  the  variable  must  then  be  translated  to  ap¬ 
propriate  sequences  of  input  and  output  actions,  leading  to  cumbersome  models. 
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